home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 5801 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.4 KB  |  108 lines
  1. Path: dawn.mmm.com!news
  2. From: kjhopps@mmm.com (Kevin J Hopps)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Q; Has anyone ever attempted to implement persistent objects?
  5. Date: 6 Feb 1996 21:37:55 GMT
  6. Organization: 3M - St. Paul, MN  55144-1000 US
  7. Message-ID: <4f8hnj$g02@dawn.mmm.com>
  8. References: <4f688s$ctc@news.cc.geneseo.edu>
  9. Reply-To: kjhopps@mmm.com
  10. X-Newsreader: TIN [version 1.2 PL2]
  11.  
  12. Peter Denecke (prd97) wrote:
  13. > I was wondering if anyone ever attempted to implement a persistent objects
  14. > system, that is, objects that can exist beyond run time.  If so, could you
  15. > give
  16. > an overview of your implementation and describe the problems you faced in
  17. > developing it?
  18.  
  19. Any object can be "trained" to dump itself to a file and read itself back in.
  20. The trouble is that in order for an object to read itself back in, there needs
  21. to actually be an object.  The difficult part about persistence is in getting
  22. the same class instantiated that was written out in the first place.
  23.  
  24. There are many 3rd party class libraries out there that have implemented
  25. persistence, with handy features of varying degree.  If persistence is
  26. your goal, rather than your own implementation of persistence, you might
  27. reach it faster if you shopped a bit for some libraries.  I think there
  28. are even some free ones out there (library vendors, speak up now).
  29.  
  30. I implemented a cheap form of it for our use internally.  We needed not only
  31. to store objects on disk, but to transfer them between processes via sockets.
  32. It turns out that the same solution works for both problems.  In a nutshell,
  33. we invented a base class (call it "Persistent") with virtual functions:
  34.     class Persistent
  35.     {
  36.     public:
  37.     ...
  38.     virtual void store(ostream& os) const;    // writes self to os
  39.     virtual void load(istream& is);        // restores self from os
  40.     ...
  41.     };
  42.  
  43. Besides this, there is a separate entity which stores and retrieves these
  44. Persistent objects:
  45.     class Storage
  46.     {
  47.     public:
  48.     ...
  49.     void store(const Persistent& obj, ostream &os);
  50.     Persistent* load(istream& is);
  51.     ...
  52.     };
  53.  
  54. Conceptually, these work like this:
  55.     void Storage::store(const Persistent& obj, ostream &os)
  56.     {
  57.     ClassInfo info(obj.classInfo());
  58.     os << info;
  59.     obj.store(os);
  60.     }
  61.     Persistent* Storage::load(istream& is)
  62.     {
  63.     ClassInfo info;
  64.     is >> info;
  65.     Persistent* obj = newPersistent(info);
  66.     obj->load(is);
  67.     return obj;
  68.     }
  69.  
  70. The "hole" in this example is the function lookup().  That could be as simple
  71. as a table that associates class names with "factory" Persistent objects that
  72. construct empty Persistent objects of their same class.
  73.  
  74. One of the problems I countered was how to make a library of these objects
  75. that is extensible.  Virtual functions go almost all the way there, but how
  76. can a user add a class and still have the existing library function lookup()
  77. find it?  Basically there needs to be some kind of "registration" mechanism
  78. that allows the insertion of factory objects into the table that lookup()
  79. uses.  I used a special constructor for derivatives of Persistent.  The
  80. convention is that exactly one object of a given class will be constructed
  81. with the registration constructor, getting it inserted into the lookup()
  82. table.
  83.  
  84. If you're going to be persistent across different machine architectures,
  85. you also need to think about data formats.  If you write things in binary
  86. format, integer byte order or floating point formats can vary.  You might
  87. choose to use text format for storing and retrieving data.  It is more
  88. portable, but is slower and results in larger data stores.
  89.  
  90. The load and store functions must be kept in sync.  If you add data
  91. members to a Persistent object, you need to update both load and store
  92. functions in the same way.  Another problem related to this is the
  93. versioning of data.  If you store some Persisent object, then update
  94. the class, you can no longer read it back in without some extra code
  95. to manage changes of this kind.  You have to decide whether this is
  96. a problem.  If it is, you need to think about whether to build versioning
  97. into the classes, or just invent new classes.
  98.  
  99. I know this is just a sketch, but I hope it helps.
  100. --
  101. Kevin J. Hopps                  e-mail: kjhopps@mmm.com
  102. 3M Company                      phone:  (612) 737-4643
  103. 3M Center, Bldg. 235-2D-57      fax:    (612) 737-2700
  104. St. Paul, MN 55144-1000         Opinions are my own.  I don't speak for 3M.
  105.     But 3M speaks for me -- I did not write the following line:
  106.  
  107. Opinions expressed herein are my own and may not represent those of 3M.
  108.